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Synopsis 


Editor’s Note 

IBM Systems Network Architecture 
(SNA) continues to be a significant 
force in the industry. The phenome- 
nal growth of LANs has not undercut 
SNA’s pervasive presence in data 
communications because SNA gives 
users methods to extend centralized 
network management away from the 
mainframes to individual, LAN- 
based workgroups. 


Report Highlights 

Not only is SNA IBM’s master plan 
for communications among IBM 
computers, terminals, and office sys- 
tems, it is also the company’s vehicle 
for interconnection with other 
industry-standard networks, such as 
X25; 


This report covers SNA’s specifica- 
tions for the structure of a network 
and the process of communications, 
including sections on Network Ad- 
dressable Units, paths between 
nodes, SNA sessions, network man- 
agement, office automation, and 
SNA architectural layering. Other 
sections explore the hardware and 
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Associate Editor 
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software in which IBM implements 
SNA and summarize its history. 


To maintain SNA’s position as a de 
facto data communications standard, 
IBM monitors SNA and makes 
changes and enhancements where 
and when necessary. IBM has consis- 
tently refined SNA since its debut in 
September 1974. This report reflects 
these changes and provides informa- 
tion on peer-to-peer networking, sub- 
areas and domains, and network 
management. To acquaint readers 
with IBM’s attention to SNA from 
January 1990 to March 1991, Table 

1 lists, by date, IBM announcements 
and enhancements relating to this 
vital architecture. 


SNA’s impact on the products and 
strategies of other vendors is re- | 
flected in Table 2, which chronicles 
SNA developments outside IBM. 


- Prominent among vendors in Table 


2 are many LAN vendors whose 
names are associated strongly with 
LANs: Banyan, Cabletron, cisco Sys- 
tems, Novell, Vitalink, and Wellfleet. 
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Table 1. IBM SNA Activity from 1/90 to 3/91 


Announced that its X.25 SNA Network Supervisory Function Release 3 features in- 


vestment protection and supports the takeover when the NSF backup facility is not 


Announced that its X.25 SNA Interconnection Version 2, Release 2, features im- 


proved system management by the XI activation without NSF and increased 


Announced the availability of its System/88 Release 6 SNA and System/88 Release 


Announced Information Network Support for X.25, TCP/IP for OS/2 Extended Edi- 


tion, and X.25 Interconnection Version 2, Release 2. 


Announced expEDite/MVS Host, a host interface-licensed program, which can be 


installed in an SNA host processor to communicate with the IBM Information Net- 


Announced TokenWay 3174 cluster controller, which connects IBM Token-Ring net- 


Announced System/88 non-SNA licensed programs, Release 10, and System/88 


SNA licensed programs, Release 7, which feature support for 4968/4585 I/O adapt- 


Introduced MAP, Ethernet, and FDDI LAN support, which provides Open Systems 


Interconnection/Communication Subsystem of SNA. 


Enhanced its OS/2 Extended Edition to Release 1.2, which now features 3270 host 


sessions based on Presentation Manager and the ability to permit any OS/2 work- 


Announced the VTAM Version 3 OSI Remote Programming Interface feature, which 


provides the same programming interface as OSI/Communications Subsystem and 
allows an SNA system to run OSI applications without installing OSI/Communica- 


1/23/90 
used. 
1/23/90 
productivity. 
1/23/90 
6 SNA Token-Ring Link Manager programs. 
1/29/90 
2/06/90 
work’s Information Exchange Service. 
3/12/90 
works to remote SNA hosts. 
4/03/90 
ers and SCSI adapter. 
4/23/90 
5/07/90 
station to act as an SNA gateway. 
6/19/90 
tions Subsystem. 
7/03/90 


Announced that SNS/SNA Gateway software from Interlink Computer Sciences will 


be offered through its Cooperative Software Program. 


ee 
Analysis 


Because of IBM’s huge installed base of products, 
as well as those from IBM plug-compatible ven- 
dors, Systems Network Architecture (SNA) will 
continue as an important de facto standard for 
data communications for some time. In March 
1991, IBM announced significant enhancements to 
SNA with the addition of Advanced Peer-to-Peer 
Networking (APPN) to the architecture. Clearly, 
IBM intends to keep SNA in the mainstream of its 
communications strategy. 

Even with the emergence of OSI, SNA will 
continue to be a focal point in IBM’s communica- 
tions strategy. Last September, during IBM’s an- 
nouncements of OSI-based products, Ellen 


JUNE 1991 


Hancock, IBM vice president and general manager, 
IBM Communications Systems, stressed IBM’s 
commitment to SNA. 

Nearly everyone who transmits data or builds 
equipment to transmit data comes into contact 
with SNA. The standard affects not only IBM and 
its users, but also those who want to establish con- 
nectivity with IBM mainframe-based information 
networks. 

IBM intended SNA to serve as the catalyst to 
eliminate the disorder that had worked its way into 
several hundred products in its teleprocessing/data 
communications lines. By its cohesive architecture, 
SNA has fulfilled that goal. Since SNA’s inception, 
IBM and its huge customer base have been capable 
of making decisive plans based on the predictable, 
gradual evolution of SNA. 

SNA also provides for the distribution of cer- 
tain communications functions to terminals and 
controllers; attachment independence via the use 
of a common (SDLC) protocol; device indepen- 
dence to allow applications software to be written 
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Table 1. IBM SNA Activity from 1/90 to 3/91 (Continued) 


8/01/90 


Enhanced its TCP/IP product for VM to feature network management capabilities 


based on SNMP to permit IBM mainframe users to centralize management of OSI, 
SNA, and TCP/IP networks. 


8/21/90 


Announced the AIX AS/400 Connection Program/6000, which allows users of RISC 


System/6000 workstations to communicate with, and access data from, AS/400 
systems. The program provides 5250 emulation under SNA or TCP/IP. 


8/21/90 


Announced Version 3 of its 4680 operating system, which permits the controller to 


link to an SNA network as a Type 2.1 node and use the LU6.2 protocol. 


9/05/90 


Announced the 3172 Interconnect Controller Model 2 that attaches multiple LANs to 


multiple host computers. It supports SNA and FDDI. 


9/05/90 


Enhanced its 3745 Communication Controller for its SNA networks to improve per- 


formance and productivity. 


9/05/90 


Announced Release 4 for MVS/ESA, VM/ESA, and VM/SP, supporting direct com- 


munication between host applications and SNA devices on LANs. 


9/05/90 


Announced NetView Version 2, which features automation ennancements for easier 


troubleshooting, NetView Graphic Monitor Facility with integrated views of SNA net- 
work status, and LU6.2 for easier creation of network management applications. 


9/05/90 


Announced LAN-to-LAN Wide Area Network Program, which allows customers to 


connect remote LANs across existing WANs without adding telecommunications 
lines. It supports Token-Ring, PC Network, Baseband and Broadband, and Ethernet 


over SNA. 
9/05/90 


Introduced Micro Channel 370 Models 110, 112, and 114, which are the only IBM 


processors to take advantage of the SNA architecture’s capability to distribute and 
install their own microcode in a distributed environment. 


9/18/90 


Introduced IBM X.25 Network Control Program Packet Switching Interface (NPSI) 


Version 3, Release 3 with ACF/NCP Version 5 Release 3, which operates in the 
IBM 3720 and 3745 communication controllers and provides enhancements to sup- 
port SNA and non-SNA devices. 


3/5/91 


Announced the Advanced Peer-to-Peer Networking (APPN) architecture as an ex- 


tension to SNA and SAA. 


3/6/91 


Announced agreements with Novell, Systems Strategies, Siemens Nixdorf, and Ap- 


ple to allow them to use its Systems Network Architecture. All of the companies 
agreed to support APPN. 


without regard to terminal and peripheral charac- 
teristics; and the reconfiguration of networks rap- 
idly and easily. 

In most network architectures, overhead is 
distributed away from the mainframe. SNA, how- 
ever, uses mainframe-based software to control 
nearly all a communication’s path and process. 
Control extends in both directions, from the input/ 
output statements of an application program to the 
printer or screen of a user’s terminal. IBM has 
modified its rigid hierarchical information net- 
works, but SNA still requires the creation and 
maintenance of extensive network configuration 
parameters within various mainframe software 
components. 

Conforming to IBM’s policy of providing 
suitable migration paths for its customers, SNA 
also accommodates new products and techniques 
that incorporate backward compatibility with 
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older, established products. This approach ad- 
vances a marketing strategy committed to main- 
taining the company’s installed base. The push 
toward SNA compatibility for all new products is 
strategic to IBM’s long-term control of its existing 
revenue streams. 


SNA Network Structure 


SNA outlines the logical structure of an IBM net- 
work by setting the configurations of its nodes and 
the links between them and their relationship in an 
overall hierarchy of control. Essentially, main- 
frame hosts control SNA networks and communi- 
cate with each other as peers. SNA also outlines the 
logical progress of communications via a layered 
architecture of processes through which a message 
must pass. 

SNA contains specifications for the devices or 
nodes in a network and for the paths between those 
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Table 2. SNA Activity from Other Vendors (3/90 to 2/91) 


Alcatel Business Systems 


Alcate! France 


Applied Computer Technology 
Aspect Telecommunications 


AT&T 


AT&T Computer Systems 
AT&T Paradyne 


Banyan Systems 


Cabletron 


Candie Corp. 


Cincom Systems 


cisco Systems 
COMPASS America 


CompuServe 


Computer Network Technology 
Data General 


Digilog 


Digital Communications Associates (DCA) 


Digital Equipment Corporation 


Digital Technology 
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Expanded its connectivity software for multivendor SNA networks with Communica- 
tion Support Facility (CSF), a product that resides on the host system and reports 
network control and management information into NetView. 


Announced two communications software packages that conform to TCP/IP and 
OSI, enabling the direct connection of TCP/IP and OSI networks to SNA networks 
without passing through the central unit. 


Enhanced its SNA Development and Test Facility, which now features testing over a 
token-ring network. | 


Introduced SNA Gateway Software, which allows its ACDs to send caller informa- 
tion to IBM host computers running integrated voice/data applications. 


Introduced StarGROUP Software SNA gateways, which allow its Unix-based Star- 
GROUP servers to act as SNA gateways to IBM systems; announced its SNA/3270 
line, which uses ISDN to link IBM 3270 terminals to SNA terminal controllers; re- 
leased additional products for users of IBM SNA networks, including 6544 Muliti- 
function Cluster Controller, 6538/9 Display Terminal, ISDN 7506 Integrated Coax 
Data Module Display Terminal, and ISDN 3270 Coax Data Module. 


Announced SNA Networking Utility and Release 1.1 of StarGROUP SNA gateway. 


Introduced 3610 and 3611 data service units, which feature network restoral capa- 
bilities, an SNA connection to NetView, and several multiplexing capabilities. 


Announced Advanced 3270/SNA and Advanced 3270/SNA Graphics options for 
VINES. 


Introduced gateways to IBM’s NetView for its Remote LANVIEW and SPECTRUM 
platforms. SPECTRUM directly links to NetView through a built-in SNA gateway. 
The gateway for Remote LANVIEW/Windows ties into SNA via NetView PC. 


Introduced Omegamon II for VTAM, an SAA/CUA-compliant performance monitor 
for IBM’s Virtual Telecommunications Access Method, which analyzes perfor- 
mances of SNA networks. 


Signed an agreement with Systems Center Inc., under which Systems Center ac- 
quired exclusive worldwide marketing rights to Net/Master SNA Network Manage- 
ment System. 


Announced a multiyear agreement with Brixton Systems to integrate SNA routing 
into internetwork routers. 


Introduced Network COMPASS, a management tool for analysis of SNA network 
operations. 


Announced CompuMode, a CompuServe SNA/SDLC protocol conversion service. 
CompuMode provides dial-up access to IBM 3270 and 5250 environments via the 
CompuServe network. 


Extended CHANNELink line to support SNA terminal control units. 


Enhanced its DG/UX operating system to Release 4.2, which features support for 
SNA software packages. 


Announced the Digilog 841 protocol analyzer, a disk-based system that decodes 
X.25, SNA, SS7, and ISDN. 


Introduced SDLC Gateway Server and 802.2 Token-Ring Gateway Server, two Mac- 
intosh LAN-to-SNA host connectivity products, which feature a choice of local or re- 
mote connections to the SNA mainframe; introduced MacirmaLAN SDLC Gateway 
Server and MacirmaLAN 802.2 Gateway Server, which provide Macintosh connec- 
tivity to the SNA environment and come in 16- and 64-user configurations; DCA and 
Microsoft announced the shipment of the DCA/Microsoft Select Communications 
Workstation, OS/2-based communications software that allows a single PC to ac- 
cess a variety of hosts and peer computers over IBM SNA networks. 


With Systems Center, Inc., announced plans to develop an EMA access module for 
Systems Center’s Net/Master SNA network management product to allow DECmcc 
Director to control IBM SNA networks; introduced the DECnet/SNA gateway for 
Channel Transport, which allows bidirectional exchange of information between 
systems on DECnet/OSI and IBM SNA networks. 


Introduced DTIX3270, a PC-based communications package that emulates IBM’s 
3174/3274 controllers and provides SNA/BSC X.25 gateways for linking NETBIOS- 
compatible LANs to remote IBM hosts. 
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Table 2. SNA Activity from Other Vendors (3/90 to 2/91) (Continued) 


Eicon 


Gateway Communications 


GE Information Services 


Groupe Bull SA 


Harris Adacom 


Hewlett-Packard 
ICL Business Systems 
ICOT 


Informer Computer Terminals 
Integrated Micro Products 


Interlink Computer Sciences 


Legent 
McDATA 


Micom Communications 
Mitek Systems 


Multi-Tech Systems 
Navtel 


NCR Comten 


NCR Corp. 
NCR GMBH 


Netlink 


Announced SNA Gateway Entry Level versions for DOS and OS/2, which lets PCs 
on NETBIOS or NetWare LANs connect remotely to IBM hosts via SDLC dedicated 
or dial-up lines, and SNA or non-SNA hosts via X.25 packet switched networks. 


Introduced the ComSystem communications system, which provides realtime ac- 
cess to diverse systems and remote information, and can be configured as an SNA 
and/or X.25 gateway in NetWare or NETBIOS LANs. 


Announced Net-Connect 3270, an asynchronous SNA link for micro-to-mainframe 
communications that allows PCs to access 3270 applications on the host. 


Enhanced its GCOS 8 operating system for the DPS 8000 and DPS 9000 main- 
frames with a range of products called Open Alliance, which enables interaction 
with Bull’s open system product family, IBM SNA networks, and other vendors’ 
systems. 


Introduced the STRATEGY 9770 intelligent token-ring gateway, which integrates 
TCP/IP Ethernet networks with IBM SNA 4/16M bps Token-Ring environments; in- 
troduced the 9570 programmable SNA gateway. 


Introduced HP SNA Distribution Services/XL interface between HP DeskManager 
and IBM OfficeVision MVS. 


Enhanced versions of PowerServer 386 systems, featuring an increase in clock 
speed to 33MHz, expanded disk storage, IBM SNA 3270 emulation, and NFS soft- 
ware based on Sun’s NFS 3.2 release. 


Introduced OmniPATH Token Ring Gateway, which can handle 128 SNA sessions. 
Introduced the Model 213PT, a laptop SNA terminal 


Introduced its XR 655 computer that features fault-tolerant X.25, TCP/IP, NFS, BSC, 
and SNA-compatible communications capabilities. 


Announced an agreement with IBM that allows IBM's sales force to sell Interlink 
products, including its SNS/SNA Gateway Product family to IBM customers in Puer- 
to Rico, Canada, and the U.S.; announced that the virtual machine version of its 
SNS/SNA gateway will support IBM’s Virtual Sequential Access Method; an- 
nounced that SNS/SNA supports IBM's 9371; acquired the program code and mar- 
keting rights to a TCP/IP-to-SNA gateway, developed by Advanced Computer 
Communications and renamed SNS/TCPaccess by Interlink. 


Announced MetNet LU6.2, a software package enabling implementation for SNA- 
Digital interoperability software. 


Enhanced LinkMaster 6100E Ethernet-to-SNA channel server with support for 
TCP/IP. 


Introduced MB3-SNA multiplexer for IBM environments. 


Introduced OpenConnect/IP Router software, which allows users to route and 
transfer data from one TCP/IP network to another over an SNA backbone. 


Introduced MultiCom3270/SNA, a remote IBM 3270 emulation system for IBM 
PC/AT/XT and compatible systems. 


Introduced 9410 Datacom Test Set, which decodes to Layer 3 for X.25 and SNA 
protocols. 


Announced Network Integration Service, which assists users in integrating stan- 
dards-based networking with SNA; announced OSI software module, an option to 
its front-end processors that enables users to run OSI applications over an IBM 
SNA backbone network; introduced Comten OSI/Communications Processor, which 
allows users to integrate Ethernet LANs with existing SNA networks without gate- 
ways or bridges; introduced Comten 5645 processor, which supports four channel- 
attached, SNA-compatible hosts or NCR mainframe application processors; 
released SNA and OSI packages for the System 3000. 


Released a suite of SNA and TCP/IP software. 


Announced Net-Manager, an OSI-compatible network management software tool 
for NCR networks, token-ring, Ethernet, X.25, and SNA networks. 


introduced SNA Link Software that allows a PC to serve as an IBM SNA router. 
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Table 2. SNA Activity from Other Vendors (3/90 to 2/91) (Continued) 


Network Software Associates 


Novell 


Oracle 


OST 
Packet/PC 


Phaser Ssytems 


Philips, The Netherlands 


Progressive Computing 
Proteon 


Pyramid Technology 


Rabbit Software 


Racal-Milgo 


Rockwell International 


Saratoga Group 


Siemens Data Systems 


Spectographics 


Spider Systems 
Sterling Software 


Sync Research 


Systems Center 


Systems Strategies 
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Enhanced AdaptSNA 3270 terminal-emulation software package with Memory 
Mizer, which reduces the amount of memory required by the emulator from 200K 
bytes to 25K bytes or 20K bytes per workstation; enhanced AdaptSNA LAN Gate- 
way, which features SNA 3270 emulation using 58K on each communicating LAN 
workstation; enhanced AdaptSNA LAN Gateway to support Novell NetWare LANs 
running IPX/SPX; announced an agreement with Future Soft Engineering in which 
the two will create a line of SNA connectivity software for the Windows 3.0 market. 


Upgraded NetWare SNA gateway and NetWare 3270 LAN Workstation to provide a 
token-ring interface. 


Introduced SQL Net LU6.2, a suite of products that extends the Oracle relational 
database management system’s support of IBM SNA networks to non-IBM operat- 
ing systems and computers; announced SSQLNet LU6.2 communications software 
that extends IBM’s SNA support to MS-DOS, VMS, AOS, and UNIX System V. 


Introduced PASS 25, a multiprotocol switch that supports X.25, X.21, X.32, videotex 
PAD, X.3, X.28, X.290 PAD, VIP, and SNA/SDLC. 


Announced Packet/FLASH bit compression software for its Packet/3270 emulation 
software for SNA networks. 


Announced NetWare SNA Router, v2.15, which uses the IBM PU2.1 LU6.2 peer-to- 
peer protocol and allows the routing of NetWare packets via SNA as part of the 
NetWare platform. 


Announced the success of the first phase of a joint program with IBM, in which the 
two companies are investigating the transparency and connectivity of the Philips 
SOPHO-S ISPBX in an IBM SNA host and Token-Ring networks. 


Introduced the LM1 Olympic Edition Protocol Analyzer for personal computers in 
IBM SNA and X.25 networks. 


Introduced the ProNet Communications Network Exchange 500, a RISC-based 
bridging router for the SNA environment. 


Announced IBM connectivity products for its UNIX-based line of MIS server sys- 
tems, which include OpenNet SNA/3270 and BAC/3270, OpenNet SNA/RJE, Open- 
Net BSC/RJE, OpenNet LU6.2, and HLLAPI. 


Announced Open Advantage Gateway, an SNA gateway that supports NetView; an- 
nounced shipment of Open Advantage Series of SNA 3270, RJE, and APPC prod- 
ucts for IBM RISC System/6000. 


Announced CMSView/II, a network management option capable of controlling SNA 
and non-SNA networks from any IBM NetView console. 


Introduced Contact Gateway inbound/outbound telemarketing systems that allow 
users to interface several ETS applications to the Galaxy ACD via SNA 3270 
protocol. 


Announced Desktop Seminar, a PC-based SNA tutorial program. 


Announced Transit 3270, an SNA gateway facility for connecting WX200 UNIX-ori- 
ented workstations to IBM networks; announced 91862 Transit Token Ring adapter 
for its MX range of Sinix-based computers, which enables SNA emulations to be 
linked transparently to a token-ring LAN, and can connect serveral Sinix systems to 
an SNA host. 


Introduced LanSet 800/3270dc, an X terminal that connects directly to an IBM 3270 
controller to allow simultaneous communications within SNA, Ethernet TCP/IP, and 
UNIX-based networks. 


Announced that SpiderAnalyzer 320-R features support for SNA protocol to allow 
decoding of SNA through the Application layer of the ISO reference model. 


Announced the availability of SUPERTRACS/SNA and TRACS/SNA products for 
VSE and VSE/SP operating systems. 


Introduced SNA Network Access Controller for Token Ring, which provides token- 
ring network connectivity for SDLC, BSC, and async terminals and cluster 
controllers. 


Announced plans to enhance its Net/Master SNA network management system to 
provide multivendor network management, including support for IBM’s LU6.2 proto- 
col and an SQL database verb set. 


Announced that Motorola has licensed its CommLink line of SNA communications 
software for the Motorola 88000 RISC microprocessor family, the Delta 8000; an- 
nounced that Wang has licensed its SNA communications software for its DYNA- 
MIX Series, an SCO UNIX-based server family. 
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Tandem Computers 
3COM 


Tri-Data Systems 


Universal Software 


Vitalink 


Wandel & Goltermann 


Wang Laboratories 


Introduced DSM/SNA View management software. 


Began shipping an OS/2 version of its Maxess Gateway, which provides for OS/2- 
to-SNA connections; introduced Maxess for Windows, a LAN-to-mainframe connec- 
tivity product that extends 3Com’s SNA gateway capability to DOS client systems 
running Microsoft Windows 3.0 or/286 under any NETBIOS-compatible network op- 
erating system. 


Announced Ethernet and token-ring LAN interface options for Netway 2000 SNA 
3270 gateways for Apple Macintosh; announced support for Mitem Corp.’s Mitem- 
View communications tools for Macintosh computers via Netway SNA 3270 gate- 
way line; enhanced Netway 2000 gateway for Macintosh with TIC-Connectivity 
Software Option and a token-ring adapter to support token-ring LANs and the 
Netway Advanced 3270 emulator. 


Released AutoTrans, a bulk data handling software product that enables IBM main- 
frame users to send and receive data sets between host CPUs in an SNA/VTAM 
network environment. 


Announced an agreement which authorizes Memorex Telex of Australia to become 
a major sales distributor and service provider for Vitalink’s token-ring and SNA 
products in Australia and New Zealand. 


Announced the DA-30 multiport dual analyzer, which can be configured to support 
Ethernet, token-ring, X.25, and SNA/SDLC. 


Enhanced IDS (Information Distribution System) to Release 3.0, which features sup- 
port for SNA communications over X.25 transports and SDLC. 


Wellfleet Communications 


Announced the Transparent Sync Pass-Thru, a software feature for its multiproto- 


col router/bridges that enables users to run synchronous traffic, such as IBM SNA 
and X.25, over a shared backbone network of bridge/routers. 


nodes. Both nodes and paths are organized in hier- 
archies of several levels (see Figure 1). The hierar- 
chy of nodes facilitates the distribution of 
functions under central control. The hierarchy of 
paths provides flexibility and redundancy in rout- 
ing. 


End Users 

Under SNA, the term “end user’’ designates either 
a person or an application program communicat- 
ing over the network with other end users. Applica- 
tion programs reside in IBM mainframes, cluster 
controllers, smart terminals, or personal comput- 
ers. A person entering data at a remote workstation 
plus the application program being accessed are 
both end users. SNA does not distinguish among 
different types of users, which are defined exter- 

~ nally to the network structure. 


SNA Nodes 

Each device in an SNA network controls a specific 
part of the network at its level of the hierarchy and 
operates under the control of a device at the next 
level. 
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IBM has specified six types of nodes in SNA, 
four of which belong to specific types of devices. 


¢ Type 5 represents a System/370 mainframe con- 
taining a Systems Services Control Point 
(SSCP) and ACF/VTAM or ACF/TCAM. 
Series/1, System/3X, and AS/400 minicomput- 
ers are excluded. 


e Type 4 represents a communications processor 
such as the IBM 3705, 3725, or 3745, which can 
operate as a front end to a host or as a remote 
communications processor. 


e Type 3 is not yet defined. 


e Type 2 units are generally end nodes with lim- 
ited routing capabilities. Type 2 represents a 
terminal cluster controller, such as the IBM 
3274 or 3276, or a remote batch terminal that 
supports SDLC. 


e¢ Type 2.1 nodes are workstations, terminal con- 
trollers, or minicomputers that incorporate 
enough intelligence to establish peer-to-peer 
communications without mainframe interven- 
tion. IBM’s Low Entry Networking supports 
peer-to-peer communications between Type 2.1 
nodes. 
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Figure 1. 
SNA Network Components 
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Components include host processors, distributed processors, communication controllers, cluster controllers, 
workstations, SNA access methods, applications subsystems, application programs, network management pro- 


Workstations 


grams, and network control programs. 


¢ Type 1 is actually located in a 37X5 ACF/NCP 
controller and represents services for terminals 
defined as pre-SNA, such as asynchronous dis- 
plays. Also represented are SDLC-supporting 
3271 (Model 11) controllers and 3767 teleprint- 
ers. Type I nodes are now obsolete. 


Network Addressable Units 


IBM designates participating devices and programs 
in SNA as network addressable units (NAUs). An 
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NAU uniquely defines and represents a device (ter- 
minal or control unit), a line, a program (applica- 
tion program in the host or cluster controller), a 
portion of an SNA access method, or a portion of 
an ACF/NCP 37XS. In an actual implementation, 
an NAU is a segment of program code that repre- 
sents a specific device or program to the network. 
There are three general types of NAUs: System Ser- 
vices Control Point (SSCP), Physical Unit (PU), 
and Logical Unit (LU) (see Figure 2). 
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Figure 2. 
Network Addressable Units (NAUs) 
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NAUs include logical units (LUs), physical units (PUs), and system services control points. NAU addresses iden- 
tify their routing locations, enabling end users to transmit data to each other. 


SSCP Some SNA networks have more than one 
An SSCP resides in the communications access SSCP. In a network with a single mainframe host, 
_method of an IBM mainframe or in the system the computer may have two access methods oper- 
control program of a small IBM computer. The ating in different partitions and controlling sepa- 
SSCP contains the network’s address tables, name- _—srate networks for different applications. In 
to-address translation tables, routing tables, and networks with more than one host mainframe, 
instructions for those tables. The SSCP establishes each host may have one or more access methods 
connections between nodes in the network and se- controlling parts of its network. In such cases, the 
lects routes for communications between those SSCPs associated with the various access methods 
nodes. It also controls the flow of information to interact as peers; each controls a domain in the net- 
ensure the network operates efficiently. In effect, work. A domain consists of one SSCP per ACF/ 


the SSCP controls the network. 
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access method, plus the physical units and logical 
units that the SSCP recognizes. 

A major exception to the rule of peer-to-peer 
communications among SSCPs is the Gateway 
SSCP in the SNA Network Interconnection (SNI) 
feature. With that feature, a number of otherwise 
independent SNA networks communicate with one 
another through a single Gateway. An SSCP in the 
Gateway controls all communications between net- 
works, acting as a master SSCP for the internet- 
work. SSCPs in the participating networks fully 
control communications within their respective 
domains and interact with one another as peers 
within their respective networks. 


Physical Unit 

A Physical Unit (PU) is a portion of a control pro- 
gram that defines a collection of services per- 
formed by the node for itself and the less 
intelligent devices attached to it. Since each partic- 
ipating device in an SNA network has one physical 
unit, for all practical purposes, node types and PU 
types are the same. 

In programmable devices, such as host com- 
puters and communications processors, the PU is 
usually implemented in software. In less intelligent 
devices, such as cluster controllers or terminals, the 
PU is usually implemented in microcode or firm- 
ware. 

In an SNA network, each PU generally oper- 
ates under the control of the SSCP and serves as an 
entry point between the network and one or more 
Logical Units. Type 2.1 nodes, however, can estab- 
lish direct, peer-to-peer communications by imple- 
menting their own session management, which can 
support single or parallel half-duplex sessions over 
multiple data links. The capability to communicate 
without mainframe intervention is a significant 
departure from original SNA strategy and is the 
key to the integration of personal computers and 
other intelligent devices into future SNA networks. 
To achieve this functionality, the LU6.2 must sup- 
port Type 2.1 nodes. In 1987, IBM released en- 
hancements that supported the integration of 
LU6.2s in T2.1 nodes into conventional subarea 
networks. 


Logical Unit | 


A Logical Unit (LU) represents an end user to the 
network. Such an end user can be an operator at a 
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terminal or an application program. The applica- 
tion may be a data entry task running at a termi- 
nal, a database update running in a host, or any 
process that serves as an end point to an SNA com- 
munication. The Logical Unit comprises those por- 
tions of the application program and the 
communications software that pass and translate 
information from the network to the application. 
The Logical Unit maintains and transmits infor- 
mation about its own status, such as its capability 
to communicate and its current communication 
activities. 

LU6.1 was an early, somewhat successful at- 
tempt to define a level 6 Logical Unit. LU6.1 is 
sufficiently compatible with LU6.2; a bridge pro- 
gram can convert LU6.1 calls to LU6.2. This capa- 
bility enables IMS applications to use LU6.2 
facilities as they are developed. 

LU6.2 is the level 6 Logical Unit that IBM 
has established as the standard for Advanced 
Program-to-Program Communication (APPC). 
APPC activates the definition of a session between 
an application program in a host computer and an 
application program in the same host, a different 
host, or an intelligent terminal (PU2.1). More sig- 
nificantly, sessions between two PU2.1 nodes, 
without host intervention, are also defined with 
APPC. 

IBM enhanced support for LU6.2 with the 
introduction of Release 3.2 of Virtual Telecom- 
munications Access Method (VTAM). Release 3.2 
supports Type 2.1 peripheral nodes, OS/2 Ex- 
tended Edition APPC, and APPC/PC Release 1.1. 
The major benefit of VTAM 3.2 is its capability to 
allow PCs, token-ring LANs, and minis to bypass 
the host and communicate with each other. 

The number of Logical Units that can reside 
at a given Physical Unit depends on the type and 
function of the Physical Unit. 


¢ LUO defines certain program-to-program proto- 
cols. 


e LUI describes a session between a host applica- 
tion and a remote batch terminal. 


e [U2 describes a session between a host applica- 
tion and an IBM 3270 display terminal. 


¢ U3 describes a session between a host applica- 
tion and a printer in the 3270 Information Dis- 
play System. 
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e U4 describes a session between a host applica- 
tion and an SNA word processing device or be- 
tween two terminal devices. 


e [U5 is currently undefined by the architecture. 


e LU6 describes Intersystem Communication 
(ISC), a session between application programs, 
usually in different host processors. Its two de- 
rivatives are LU6.1 and LU6.2. 


e U7 describes a session between a host applica- 
tion and an IBM 5250 display terminal. 


SNA Sessions 
All communications in SNA occur within sessions 
between NAUs. A session Its a logical, two-way con- 
nection between two NAUs over a specific route 
for a specific period of time. The connection and 
disconnection of any session, as well as any abnor- 
mal occurrences within the session that affect com- 
munications, are responsibilities of the SSCP. 
SNA defines types of sessions. Most types 
describe sessions that last for short periods of time 
and perform some network control, diagnostic, or 
management function. 


Types of Sessions 


¢ SSCP-to-PU sessions—an SSCP requests status 
or diagnostic information from a PU within its 
domain, and the PU responds appropriately. 


¢ SSCP-to-LU sessions—the SSCP requests status 
or diagnostic information from an LU, and the 
LU responds appropriately. 


e SSCP-to-SSCP sessions—two SSCPs in the 
same or different domains communicate to ex- 
change information. The two SSCPs can reside 
in different access methods within the same 
host computer. 


e LU-to-LU sessions—two LUs exchange infor- 
mation. All end-user communication in SNA 
takes place over LU-to-LU sessions. 


Sessions between Logical Units 

SNA defines different types of LU-to-LU sessions 
for different functions, depending on the types of 
logical units participating and the nature of the 
communication between them. The definition of a 
session type specifies the protocols, character sets, 
and control functions for that type of session. IBM 
currently defines eight types of sessions between 
logical units. Since the logical units at both ends of 
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a conversation must be of the same type, a given 
logical unit can participate in only one type of ses- 
sion. Also, the names of logical unit types identify 
types of sessions. An individual SNA session is 
characterized by its session type and by the charac- 
teristics of its virtual route; the combined defini- 
tion is called a session profile. LUs at either end of 
a session can negotiate certain characteristics of 
the session profile, such as class of service and pri- 
ority, before beginning the session. 


APPC 

APPC is IBM’s term for a set of SNA facilities de- 
signed to provide enhanced support for distributed 
transaction processing. The goal of APPC is to pro- 
vide complete interconnection compatibility for all 
levels of an SNA system below the application. 
APPC is one key to resolving the current PC-to- 
mainframe connection dilemma, which involves 
PCs emulating less capable 3270-type terminals to 
access mainframe resources. The emulation ap- 
proach is inefficient for the mainframe and the PC 
because it forces each one to service the screen-by- 
screen transfer of data inherent in 3270-oriented 
communications. The problem becomes particu- 
larly acute when the PC initiates any type of file 
transfer; multiple PCs initiating file transfers while 
emulating 3270s can quickly overtax even a large 
mainframe. 

The advent of intermediary departmental 
systems servicing local PCs has solved this prob- 
lem. The addition of APPC capabilities, combined 
with the remote front-end control of PC LANs, 
may prove to be even more practical. 


APPN 

Advanced Peer-to-Peer Networking (APPN) is a 
distributed networking feature that IBM has incor- 
porated into SNA for optimized routing of com- 
munications between devices. APPN simplifies the 
process of adding workstations and systems toa 
network, thereby enabling users to transmit data 
and messages more quickly. APPN also supports 
transparent sharing of applications in a distributed 
computing environment. Since APPN supports 
direct communication among users on a network, 
it facilitates the development of client/server com-_ 
puting, in which workstation users anywhere on a 
network can share processing power, applications, 
and data regardless of the location of the informa- 
tion. 
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APPN sharpens SNA performance by sup- 
porting more flexible workstation installation and 
faster communication between end users. Users 
can add APPN devices to existing SNA networks 
without disrupting the network and rewriting the 
operating system and other software because of 
APPN’s nonhierarchical approach. 

With APPN, the network architect defines 
points on the network (workstations or larger de- 
vices) as network nodes or end nodes. Network 
nodes serve as the backbone of the APPN network 
by providing directory services and routing com- 
munication through each other to attached end 
nodes. The multiple network nodes of an APPN 
network share many of the routing and control 
functions previously centralized in software in the 
host computer. 

In addition, APPN unlocks the potential for 
fast and flexible communications offered by IBM’s 
Advanced Program-to-Program Communications 
(APPC) protocols. APPN supports and enhances 
electronic mail, file exchange, and the sharing of 
those applications that conform to APPC proto- 
cols. APPC 1s the primary protocol for communi- 
cation over APPN networks. 

IBM has also incorporated APPN end node 
specifications into its published networking specifi- 
cations, Common Communications Support 
(CCS), included in Systems Application Architec- 
ture (SAA). 

APPN debuted in 1986 in networks of 
System/36 minicomputers. In 1988, IBM put 
APPN in the AS/400 midrange computer net- 
works. In 1990, the company added APPN to the 
DPPX operating system and enhanced Virtual 
~ Telecommunications Access Method. In 1991, 
IBM extended APPN functionality to OS/2. The 
AS/400 and OS/2 support for APPN enables appli- 
cations from the AS/400 to be accessed by PS/2 
workstation users. 


Subareas and Domains 

Large SNA networks are addressed and managed 
through a system of smaller network units, similar 
to the public telephone network for voice commu- 
nications. These units consist of subareas and do- 
mains. Subareas assign addresses to each NAU. 
Domains assign management control for each 
NAU. 
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NAUs have unique addresses for identifying 
themselves and sending messages in an SNA net- 
work. These addresses comprise a subarea address 
and an element address within the subarea. The 
subarea address identifies a large piece of the net- 
work, a subarea, to which each NAU is assigned. 
Subareas are like area codes in the telephone net- 
work. In addition, each mainframe comprises its 
own subarea (see Figure 3). 

Systems programmers in organizations deter- 
mine subarea addressing conventions. Subareas 
support a maximum of 8,000 addresses. In the 
early 1980s, however, IBM’s larger users began 
running out of address space. SNA users solved 
this problem by: 


1. Partitioning their SNA networks into smaller 
subsections through SNA Network Intercon- 
nection (SNI), allowing addresses in one SNA 
network to be mapped to addresses in another 
through a gateway. In this manner, different 
networks can have the same addresses. SNI 
provides access for up to 256 separate net- 
works. 


2. Expanding the element address. Although IBM 
extended the address field from 16 to 23 bits, 
the subarea address remains constant at 8 bits. 
Users can, however, expand the element ad- 
dress from 8 to 15 bits. This optional subarea 
extension adds overhead, however, to the 
datastream. 


3. Establishing domains, which are groups of 
LUs, PUs, and other network resources under 
the control of a single SSCP (see Figure 4). A 
domain can consist of two or more subareas. 
Domains foster more sophisticated networking 
under SNA, such as backup in network failure, 
resource sharing, and multihost networking. A 
simple domain could contain a host computer, 
one communications controller, and a cluster 
controller and distributed minicomputer with 
attached workstations. 


Paths between SNA Nodes 

SNA defines a hierarchy among paths between 
nodes and, like most entities defined in SNA, the 
hierarchy contains physical and logical compo- _ 
nents. 


© 1991 McGraw-Hill, incorporated. Reproduction Prohibited. 
Datapro Research Group. Delran NJ 08075 USA 


petoro enone on staal Sse «SAAD 
ommunications ystems Networ 
Architecture (SNA) Technology Reports 


Figure 3. 
SNA Network Subarea 
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An SNA subarea consists of a host or communication controller node and its peripheral nodes. 


SDLC Links: Devices in an SNA network can be supported—if at all—under SNA only for back- 


connected over a high-speed I/O channel or a Syn- ward compatibility. IBM channel connections are 

chronous Data Link Control (SDLC) link, whichis essentially outside the concerns of data communi- 
IBM’s data link control protocol. Pre-SNA proto- cations. 

cols, such as IBM’s Binary Synchronous Communi- SDLC links connect communication control- 
cations (BSC), and non-SNA communications lers to one another and to terminal cluster control 

techniques, such as start/stop (asynchronous), are units, batch terminals, and some display devices. 


Depending on the requirements of an individual 
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A domain consists of an SSCP and the network resources that it can control. 


configuration, two communication controllers can into transmission groups, which comprise one or 


be connected by a number of parallel SDLC links. more parallel links with the same transmission 
Here, “parallel” refers to the parallel paths fol- characteristics, such as data rate, delay, security, 
lowed by the individual links—not to a parallel, and likelihood of error. A transmission group ap- 
byte-at-a-time communications technique. SDLC pears to an end user as a single link; the commun1- 
is a bit serial protocol. Parallel SDLC links back cation controller decides which links within the 
one another up in the event of one link’s over- transmission group will carry specific messages. 
crowding or failure. The individual links are transparent to the user, 
who sees only the transmission group. With the 
Transmission Groups: Parallel SDLC links be- IBM 37XS5, users can establish up to eight trans- 
tween two SNA nodes can be arranged logically mission groups between any two controllers. 
JUNE 1991 © 1991 McGraw-Hill, Incorporated. Reproduction Prohibited. 
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Explicit Routes: An SDLC link between a commu- 
nication controller and a cluster controller or ter- 
minal is called a peripheral link. Since only one 
link at a time in SNA can connect a terminal unit 
to a communication controller, peripheral links 
cannot belong to transmission groups. 

The simplest SNA networks—those con- 
trolled by a single host with a single front-end pro- 
cessor and no remote communication controllers— 
use only peripheral links to communicate with 
their terminals. More complex networks involving 
more than one host or more than one communica- 
tion controller use transmission groups between 
the communication controllers and peripheral 
links between the communication controllers and 
the terminals. 

In such a network, a transmission can be 
routed through more than one communication 
controller on its way from source to destination. Its 
path can consist of the channel from the host to the 
communication controller, one or more transmis- 
sion groups between successive communication 
controllers, and the peripheral link between the last 
communication controller and the terminal. In 
SNA, the position of a path not including the pe- 
ripheral link is an explicit route, which defines the 
physical characteristics of a specific path between 
two subarea-node end points in an SNA network; 
in SNA, these characteristics are called class of ser- 
vice. An explicit route, then, is a specific path be- 
tween two end points that offers a specific class of 
Service. 

In an SNA network where there is more than 
one explicit route between two end points, the last 
communication controller in the path connects the 
destination end point over a peripheral link. The 
explicit route thus selected remains in effect for the 
duration of a session between two end points. 

The individual transmission groups that com- 
prise an explicit route are redundant by design; 
each can contain a number of physical links that 
can back up one another. Sometimes, however, an 
entire transmission group can become unavailable 
because of link failures or controller failure. 


Virtual Routes: SNA’s specification of the paths 
between subarea nodes contains one final logical 
element. The transmissions in a session between 
two end points can have one of three priorities. A 
transmission’s priority governs its degree of access 
to an explicit route. A session’s priority, plus its 
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explicit route, is the session’s virtual route, which 
defines the complete logical path between the 
subarea-node end points on an SNA network. 


SNA Network Management 
In IBM’s view, network management encompasses: 


¢ problem management, or managing a network 
outage from the time it is detected until the 
time it is resolved; 


¢ performance and accounting management, 
which monitors the network’s health, fine-tunes 
network operation to improve performance, 
and tracks system usage; 


¢ configuration management, which takes inven- 
tory of network components and their logical 
relationships; and 


¢ change management, which reconfigures the 
network to meet changing conditions. 


NetView: IBM’s NetView centralizes SNA’s net- 
work management, providing uniformity and a 
single point of access to previously separate func- 
tions. It supports consistent use of program keys, 
application uniformity, and color graphics. IBM 
introduced NetView Release 2 in 1987, which 
made NetView easier to use, provided a higher 
level of automation, and offered distributed 
NetView application support. Net View Release 2 
had an open architecture that supported linkages to 
many competitive hardware and software control 
elements. Using NetView, network managers can 
monitor network performance/response times, pin- 
point hardware and software errors, monitor and 
test the status of analog lines, and configure the 
3728 matrix switch and modems at remote sites. 

In September 1990, IBM introduced NetView 
Version 2 Releases | and 2. NetView Version 2 
Release 1 includes the NetView Graphic Monitor 
Facility, the NetView Bridge, and the NetView In- 
Stallation Facility. NetView Version 2 Release 2 
provides LU6.2 transport capability and enhance- 
ments to Net View automation features and ex- 
tends the NetView Graphic Monitor Facility 
support to the VM/ESA environment. LU6.2 al- 
lows users to write network management applica- 
tions that interact with Net View for SNA and non- 
SNA devices. 
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NetView/PC: NetView/PC, introduced shortly af- 
ter NetView, is a multitasking personal computer 
subsystem that extends passive Net View monitor- 
ing functions to token-ring LANs and other com- 
munications systems or programs developed by 
users or third-party vendors. It provides applica- 
tion programs with the means to forward generic 
alerts not requiring unique support in Net View 
and participates in IBM’s SAA. It also forwards 
Service Point Command Service (SPSC) Net View 
commands to NetView/PC applications and re- 
turns replies to Net View from the applications. 
NetView Release 3 extended Net View’s capability 
to automate many of the control system’s manage- 
ment facilities. 

Net View also plays an important part in fine- 
tuning a network. The NetView Command Facility 
enables the operator to give VTAM commands and 
collect VTAM console data produced by TNSTAT, 
VTAM Internal Trace, and DISPLAYS. 

Net View/PC Version 1.2.1, released in March 
1990, extends Net View/PC’s functionality. It has 
been enhanced to provide the Net View/PC Gate- 
way function and the option of selectively install- 
ing Net View/PC, Net View/PC Gateway function, 
or both. Users can install the Remote Console Fa- 
cility with these functions. 


Office Automation through SNA 
Through APPC, SNA extends its basic capabilities 
that support distributed office automation (OA) 
and related functions. IBM has concentrated OA in 
the mainframe environment (VSE, MVS, and VM 
operating systems), with links to IBM minicomput- 
ers, personal computers, and associated OA prod- 
ucts. Its major OA offering is Distributed Office 
Support System (DISOSS), an application program 
of IBM’s Customer Information Control System 
(CICS). DISOSS is a document management and 
distribution facility that uses two office informa- 
tion architectures to format and transmit text doc- 
uments: Document Content Architecture (DCA) 
and Document Interchange Architecture (DIA), 
respectively. Increasingly, DISOSS products and 
third-party vendors use a facility called SNA Dis- 
tribution Services (SNADS) to communicate with 
other DISOSS products over distributed office net- 
works. 

DCA is an APPC-based datastream that spec- 
ifies a document’s content. It translates human lan- 
guage into printed or displayed office documents. 
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DCA defines type fonts, formatting, pagination, 
headings, and control information, for text trans- 
mission. 

DIA is an APPC LU6.2 Transaction Services 
Architecture that specifies the protocols and struc- 
tures for document interchange through an office 
network. It consists of several service categories 
that distribute documents or messages to one or 
more recipients; allow users to store and retrieve 
documents in a library; and process document ap- 
plications, convert formats, and modify document 
descriptors. 

SNADS is a set of Distribution Transaction 
Programs that runs in an APPC LU6.2 environ- 
ment. It provides asynchronous communications, 
especially useful for OA applications. Although 
compatible with DIA, SNADS 1s the preferred 
method for distributing documents. The primary 
application for SNADS is electronic mail, making 
it IBM’s alternative to the CCITT’s X.400 proto- 
col. 


SNA Layers 


SNA is a layered architecture, similar to—but not 
identical with—the ISO’s Open Systems Intercon- 
nection (OSI) reference model (see Figure 5). The 
OSI model and SNA define seven functional lay- 
ers. Specifications that correspond to some of the 
uppermost (Application) layers of the OSI model 
are imbedded in IBM’s SAA architecture and not 
in SNA proper. SNA’s seven layers correspond 
roughly to the following seven layers of the OSI 
model: Physical, Data Link, Network, Transport, 
Session, Presentation, and Application. There are 
differences in the handling of routing and in defin- 
ing the boundary between the lower “transport 
system” layers and the upper “logical control’’ lay- 
ers. 

In a layered architecture, the communications 
process is divided into functional layers, each of 
which passes data to and receives data from the 
layers immediately above and below it in the archi- 
tecture. A message passing between two end points 
must pass through all layers in the sending node, 
and again through all layers in reverse order in the 
receiving node. In some architectures, a message 
may pass through some of the lower layers each 
time it encounters an intermediate node. 

Each layer deals with a message with a spe- 
cific degree of intelligence and at a specific level of 
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Figure 5. 
SNA Layers 
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TRANSACTION SERVICES distributed data 
base access; document interchange, etc. 


PRESENTATION SERVICES formats data; 
coordinates the sharing of resources. 


DATA FLOW CONTROL synchronizes data 
flow, between end-points of a session. 


TRANSMISSION CONTROL paces data 
exchanges. 


PATH CONTROL routes data; controls 
data traffic. 


DATA LINK CONTROL transmits data 
between adjacent nodes. 


PHYSICAL CONTROL connects adjacent 
nodes physically and electrically. 


abstraction. The Data Link layer, common to SNA 
and the OSI model, deals with a message as a 
stream of bits in a specific order. The Path Control 
layer in SNA (which includes functions of the Net- 
work layer in the OSI model) deals with a message 
as a packet of data addressed from an application 
in the sending node to an application in the receiv- 
ing node. The NAU Services Manager in SNA 
(which corresponds to the OSI model’s Presenta- 
tion layer) deals with a message as a set of intelligi- 
ble characters to be presented to the application 
from the network, or to the network from the ap- 
plication, according to a predetermined set of 
rules. 
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The division of the communications process 
into layers allows network architects flexibility in 
updating, revising, or correcting the communica- 
tions process. Designers (and, sometimes, users) 
can alter the process at one layer without affecting 
the other layers, as long as the changes do not af- 
fect the way information is passed to and from the 
altered layer and its adjacent layers in the architec- 
ture, and as long as such changes are consistent 
throughout the network. 

A layered architecture also allows the substi- 
tution of one set of protocols for another at the 
lower layers. To the processes at a given layer of 
such an architecture, all lower layers are simply 
part of the network. Thus, although some routing 
problems exist for more complex networks, the 
X.25 packet-switching protocols for the Data Link 
and Path Control layers of SNA can be substituted 
to allow SNA devices to communicate over X.25- 
based public networks. In some implementations 
of a layered architecture, processes at the upper 
layers can select which of several sets of low-level 
protocols they will use for specific communica- 
tions. 

From the bottom up, SNA’s seven architec- 
tural layers are: 


e Physical 

¢ Data Link 

¢ Path Control Network 

e Transmission Control Services 
¢ Data Flow Control Services 

e Presentation Services 


e Transaction Services 


At each end point of a transmission, a message 
must pass through all seven layers. At each inter- 
mediate node, such as a communication controller, 
a message must pass through the three lower layers 
twice, once on receipt by the controller and once 
on retransmission. 


The Physical Link Layer: The Physical Link layer 
is SNA’s lowest and simplest layer. It deals with 
the physical and electrical interface to the telecom- 
munications network and is distinct from the logi- 
cal network layers above. The physical layer 
specifies connector characteristics and voltage and 
current levels. IBM does not promote much activ- 
ity at this level, leaving interface specifications to 
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the CCITT and other standards organizations. 
Many different interfaces are supported, and any 
can be used for SNA as long as they are embraced 
by IBM. 


The Data Link Layer: Synchronous Data Link 
Control (SDLC) is one of four Data Link protocols 
defined by SNA. The others are S/370 channel, 
token-ring, and X.25. Some implementations of 
the architecture can support BSC, a pre-SNA IBM 
protocol still widely used, or non-IBM protocols 
such as the CCITT’s HDLC or the various asyn- 
chronous line disciplines. . 

Structurally, SDLC is a subset of the CCITT’s 
High Level Data Link Control (HDLC) link proto- 
col, tailored to better serve IBM communications. 
SDLC 1s a bit-oriented, serial protocol, represent- 
ing control information as the binary values of in- 
dividual bits in predefined positions. Such 
protocols are much more efficient than earlier 
byte-oriented, serial protocols, which use the val- 
ues of entire 8- or 16-bit characters to represent 
control functions. In a bit-oriented protocol, the 
information on the function of a series of bits need 
not be transmitted as data, since such information 
is contained in the positions of bits in the series. 


The Path Control Layer: Routing and flow control 
are the two major functions of the Path Control 
layer. Routing takes place at every node on the 
path between two LUs on the network. At the be- 
ginning of a session, the sending and receiving 
nodes and all nodes in between cooperate to select 
the best available virtual route for that session. 
During the session, each node along that route se- 
lects the next available link in the selected trans- 
mission groups for each message within that 
session. 

Every LU on a network has a network name, 
a mnemonic known to the end users and to appli- 
cations that might communicate with that LU. The 
result of address layering is that an end user need 
know only the name of a terminal or process on the 
network to communicate with it; the end user need 
not know where that terminal or process resides in 
the network. | 

The routing function also assigns a class of 
service to each session. The SSCP passes a list of 
virtual routes meeting a requested class of service 
to the Path Control layer, which activates the first 
available virtual route in the list. 
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To improve transmission efficiency, the Path 
Control layer at each node along a session’s path 
can segment messages—divide long messages into 
segments so the Data Link layer can transmit them 
in separate SDLC frames. The segmenting function 
ensures that the transmission facilities’ efficiency 
does not depend on arbitrary message lengths. 

The final flow control function of the Path 
Control layer is virtual route pacing, which ensures 
that traffic along a virtual route shared by a num- 
ber of sessions does not overly congest that route. 


The Transmission Control Services Layer: The 
Transmission Control Services layer paces mes- 
sages for individual sessions. This session-level pac- 
ing function primarily ensures that a transmitting 
NAU in session with a receiving NAU does not 
transmit more data than the receiving NAU can 
handle. To perform session-level pacing, the two 
NAUs at either end of a session negotiate the size 
of a pacing group at the beginning of the session. A 
pacing group is the largest number of messages that 
the transmitting NAU can send before it receives a 
pacing response from the receiving NAU, telling it 
that it can resume sending. Session-level pacing 
occurs in two stages along a session’s route: be- 
tween the host NAU and the communication con- 
troller and between the communication controller 
and a peripherally attached terminal NAU. 

This layer also performs encryption when the 
application program requests it. SNA offers man- 
datory and selective session-level encryption. Man- 
datory encryption encrypts all messages within a 
session; selective encryption codes only those mes- 
sages identified by an enciphered data indicator 
embedded in the messages. 


The Data Flow Control Services Layer: The Data 
Flow Control Services layer handles the order of 
communications within a session by establishing 
chains and brackets of data and by maintaining one 
of three send/receive modes. 

A chain is a group of messages associated log- 
ically for transmission in one direction on the net- 
work. A bracket is a group of messages associated 
logically for two-way transmission on the network. 
The Data Flow Control Services layer establishes 
chains and brackets for two purposes: error control 
and contention control. 

When an error occurs in one message of a 
chain of messages, the receiving node notifies the 
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Data Flow Control layer of the sending node, and 
the sending node then holds the untransmitted por- 
tion of the chain. If the LU detects the error and 
determines that a protocol violation caused the 
error, the session is terminated. If the application 
program detects an error, uSer error recovery Oc- 
curs. 

The three send/receive modes established and 
maintained by this layer are full-duplex, half- 
duplex flip-flop, and half-duplex contention. In 
full-duplex mode, each participating LU can trans- 
mit at any time, whether or not the other LU is 
transmitting. In half-duplex flip-flop mode, the 
participating LUs transmit alternately; at the end 
of a chain, the LU currently transmitting can pass 
permission to transmit to the other LU. (LU6.2 
uses only half-duplex flip-flop.) In half-duplex con- 
tention mode, one LU is designated as dominant at 
the beginning of a session; either LU can begin 
transmitting at any time, but if the dominant LU is 
transmitting when the other LU attempts to trans- 
mit, the other LU must withhold its transmission 
until the dominant LU has finished transmitting 
its current chain. 


Presentation Services Layer: The Presentation Ser- 
vices layer defines the protocols for program-to- 
program communication and controls 
conversation-level communication between trans- 
action programs by: 


¢ loading and invoking transaction programs; 
* maintaining conversation send-and-receive 
mode protocols; 


¢ enforcing correct verb parameter usage and se- 
quencing restrictions; and 


¢ processing transaction program verbs. 


Transaction Services Layer: The Transaction Ser- 
vices layer, the highest architectural layer defined 
by SNA, implements the following service transac- 
tion programs in an SNA network: 


* operator control of LU-to-LU session limits; 


¢ Document Interchange Architecture (DIA) for 
document distribution between office systems; 
and 


¢ SNA Distribution Services (SNADS) for asyn- 
chronous data distribution between distributed 
applications and office systems. 
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The Transaction Services layer also provides con- 
figuration, session, and management services to 
control the network’s operation. SSCP-to-PU ses- 
sions use configuration services to control re- 
sources associated with the physical configuration. 
Configuration services activate and deactivate 
links, load same-domain software, and assign net- 
work addresses during dynamic reconfiguration. 

SSCP-to-SSCP and SSCP-to-LU sessions use 
session services to establish LU-to-LU sessions. 
Session services translate network names to net- 
work addresses, verify user access authority, and 
select session parameters. 

SSCP-to-PU and SSCP-to-LU sessions use 
management services to control the operation for 
the network. Management services handle network 
problems, performance and accounting informa- 
tion, network configuration, and changes in the 
network. 

Specific protocols perform services equiva- 
lent to those of the OSI reference model’s Applica- 
tion layer. The first of such protocols make up 
IBM’s Office Information Architectures: the Docu- 
ment Interchange Architecture and the Document 
Content Architecture. Within SNA, these architec- 
tures use the Advanced Program-to-Program Com- 
munications services of LU6.2. 


Implementing SNA 


SNA Hardware 


Host Computers 
SNA originated as a communications architecture 
oriented toward centralized control by mainframes 
that use the System/370 architecture. It is evolving 
toward greater control of IBM systems that use dif- 
ferent architectures. The IBM mainframes that 
support full SNA configurations are the System/ 
370 and its direct descendants: the 303X family of 
medium-to-large mainframes, the 308X and 309X 
families of large mainframes, and the 4341 and 
4381 mainframes. The 9370 superminis and the 
smaller members of the 4300 family (the 4321, 
4331, and 4361) support limited SNA configura- 
tions through an integrated communications 
adapter (ICA) in place of a front-end communica- 
tions processor. 

IBM System/3X and AS/400 computers can 
function as hosts for small SNA networks of their 
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own and as Type 2.0 or Type 2.1 intelligent term1- 
nals in mainframe-based SNA networks. IBM 8100 
processors can perform as hosts in 8100-based 
SNA networks and as distributed processing nodes 
in mainframe-based configurations. The 8100 was, 
however, “functionally stabilized”’ by IBM in 
1986, meaning that further development of SNA 
capability for the processor is highly unlikely and 
that customers are wise to abandon plans for 8100 
processors in the future. All these systems can par- 
ticipate in distributed networks as peers, but can 
function only as terminals in networks controlled 
by mainframes. 

System/88 supports several SNA programs 
including Release 6 SNA Licensed Program and 
Release 6 SNA Token-Ring Link Manager; 
System/88 Primary SNA; System/88 Secondary 
SNA; System/88 SNA-3270 Terminal Emulation; 
System/88 SNA Cluster Controller; and System/88 
SNA Network Interface Support. 

IBM Enterprise System/9370 (Models 10, 12, 
and 14) support entry points into an SNA network. 


Communication Controllers 

SNA communication controllers from IBM include 
the 3705, 3720, 3725, and 3745. The 3705, 3720, 
3725, or 3745 can function as front-end processors 
for mainframes or as remote communication con- 
trollers. These devices use some version of ACF/ 
NCP/VS when operating in SNA networks; they 
can also support pre-SNA and start/stop communi- 
cations through versions of the Emulation Program 
and Partitioned Emulation Programming. Newer 
versions of ACF/NCP/VS support pre-SNA batch 
terminals through a program called Non-SNA In- 
terconnect. 

In September 1984, IBM unveiled the 3710 
Network Controller, which concentrates SDLC and 
selected asynchronous and BSC protocols over 
SNA/SDLC and X.25 links. The 3710 is supported 
by SNA as a cluster controller and can share lines 
with 3710s and other SNA devices; it connects to 
one or more 37X5s and can transmit concentrated 
traffic over single or multiple upstream links. 

The 3710 opened up SNA to the asynchro- 
nous world by providing an IBM-endorsed asyn- 
chronous gateway into SNA networks. The 3710 
connects upstream to a 3705, 3720, 3725, or an- | 
other 3710; it connect downstream to SNA an 
non-SNA devices. | 
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The company stepped further into the ASCII 
world in 1985 by introducing the 3708 Network 
Conversion Unit. The 3708 is a 10-port unit that 
supplies line conversion, protocol conversion, pro- 
tocol enveloping, and ASCII pass-through capabili- 
ties. It allows asynchronous devices to emulate 
IBM 3270 synchronous displays and printers. The 
3708 operates with IBM’s System/370, 303X, 
308X, 3090, and 43XX processors; 8100 systems; 
System/38 and AS/400 processors; 3710 Network 
Controller; and Rolm’s CBX II voice/data PBX. 

In February 1988, IBM introduced the 3745, 
a front-end processor that demonstrates a substan- 
tially improved price/performance ratio over the 
3725. The 3745 increases the number of lines that 
can be practically supported (as opposed to physi- 
cally attached) and is entirely compatible with the 
3720/3725 family. It improves capabilities for 
X.25 and Token-Ring LAN attachment. 

The 3174 Subsystem Control Unit supports 
208 SNA LUs on Models 11L, 11R, 12R, and 13R. 
For Models 61R and 62R, the 3174 supports 84 
LUs. An optional 16/4M bps Token-Ring Network 
Gateway feature offered with Models 11L, 11R, 
12R, 61R, and 62R provides data passage between 
an IBM SNA host and terminals attached to an 
IBM Token-Ring Network downstream of the 
3174. In September 1990, IBM released 3174 
Model H, which has enhanced system management 
capabilities that can IML SNA network 3174s from 
a central NetView operator’s console. | 

In the March 1991 announcements, IBM in- 
troduced the 3174 Establishment Controller APPN 
Licensed Internal Code (LIC) feature, which adds 
support for advanced peer-to-peer networking 
(APPN) to the existing communication capabilities 
of configuration Support-C of the 3174, Release 1. 
The APPN feature supplies the network node func- 
tion of APPN, and the peer communication LIC 
feature supports the use of LAN applications on 
DOS workstations that are attached via 3270 wir- 
ing to the 3174. 

In September 1990, IBM announced that the 
3172 Interconnect Controller, in conjunction with 
VTAM Version 3 Release 4, can enhance the use of 
existing LAN resources within SNA. At the same 
time, IBM released Model 1 of the 3172, which 
supports SNA, as well as other multivendor proto- 
cols and Model 2 of the 3172 with an FDDI 
adapter that supports VTAM/SNA and TCP/IP 
data flows. 
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Terminals 

Most IBM batch, display, and printing terminals 
support SNA communications at the PU1 level. A 
number of small IBM computers can function as 
Type 2 (3270) display terminals and as Type 2.1 
intelligent terminals in mainframe-based IBM net- 
works. These devices include the Systems/34, /36, 
and /38; the AS/400; the IBM 8100; the Series/1; 
the 3270 Personal Computer; and various personal 
computer models equipped with an IBM SDLC 
card or third-party terminal emulation card. 


SNA Software 


Operating Systems 

Most SNA processing on IBM mainframes takes 
place in the telecommunications access methods 
that reside on those mainframes; the mainframe 
operating system performs few, if any, SNA func- 
tions. In general, standalone IBM operating sys- 
tems, such as MVS/SP 1.3 (MVS/370), MVS/XA, 
DOS/VSE/AF, and VM/SP, support current SNA 
levels. Older standalone operating system versions, 
such as DOS/VS, OS/VS1, and SVS, have been 
phased out of development. 

Originally, VM/SP hosts could not connect to 
SNA networks. This situation was temporarily cor- 
rected by the VTAM Communications Network 
Application (VCNA), which permitted consider- 
able cross-connection for both SNA host-attached 
terminals and VM/SP host-attached terminals. Re- 
lease 4 of VM/SP made VCNA obsolete due to a 
special VM/SP feature that allows VTAM to run 
under VM in native mode in the same virtual ma- 
chine as other communications programs. 

VM/SP, DOS/VSE, and SSX/VSE cannot 
support ACF/TCAM. Until recently, a special ver- 
sion of ACF/VTAM, called ACF/VTAME, was re- 
quired for these operating systems to support SNA 
in smaller configurations with a communications 
adapter. By including equivalent NCP in the code 
that supported the integrated adapter, the newer 
versions of ACF/VTAM replaced ACF/VTAM for 
these systems. 

In December 1989, IBM enhanced ACF/ 
VTAM to improve SNA performance. In Septem- 
ber 1990, IBM released VTAM Version 3 Release 
3 for the company’s VSE/ESA and VM/ESA oper- 
ating systems and VTAM Version 3 Release 4 for 
MVS/ESA, VM/ESA, and VM/SP operating sys- 
tems. Release 4 supports direct communications 
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between host applications and SNA devices on sev- 
eral types of LANs, including those conforming to 
FDDI. 

Operating systems on other IBM computers, 
such as DPPX and DCPX on the IBM 8100; CPF 
on Systems/34, /36, and /38; and OS/400 on the 
AS/400, can participate in SNA networks without a 
separate communications access method. The req- 
uisite logic is either part of the operating system or 
an operating system feature. In other words, the 
SSCP is built into the control programming of 
these operating systems. In networks with IBM 
mainframes as hosts, these systems communicate 
as terminals. 


SNA Access Methods 

A telecommunications access method provides a 
single interface to communications facilities for all 
application programs running under a computer’s 
operating system. With an access method in place, 
application programmers need not write special 
sets of routines for each application. They must 
provide only input and output statements suitable 
for routines in the access method. 

In SNA, the access method is the most impor- 
tant network software. In mainframe networks, 
both the SSCP and the PU type 5 are portions of 
the access method’s code. The access method con- 
nects and disconnects sessions; maintains informa- 
tion on the configuration of the network; and 
gathers information on the status of the network’s 
nodes, links, and activity of its sessions. Through a 
series of network management programs, the ac- 
cess method communicates with network operators 
and allows them to detect, record, and correct 
physical and logical errors. 

There are currently two SNA access methods: 
ACF/VTAM and ACF/TCAM. ACF/VTAM 1s de- 
scended from the Virtual Telecommunications Ac- 
cess Method (VTAM), the first SNA access 
method. ACF/VTAM, specifically designed for 
SNA, is the only mainframe access method that 
IBM is now actively developing. ACF/TCAM is 
descended from an earlier SNA access method, the 
Telecommunications Access Method (TCAM). 

The ACF designation stands for “‘advanced 
communications function” and has prefixed the 
names of all SNA access methods and network con- 
trol programs since the introduction of multisys- 
tem networking. An ACF access method, either 
ACF/TCAM or ACF/VTAM, must exist in each 
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host of any SNA network in which more than one 
IBM mainframe participates. The ACF versions of 
TCAM and VTAM were originally sets of enhance- 
ments offered separately from either basic access 
method. Both ACF/TCAM and ACEF/VTAM are 
now marketed as complete access methods. 

In general, VTAM handles communications 
more efficiently for the mainframe; it transfers 
messages directly between communicating end 
points. TCAM handles communications more effi- 
ciently for the terminals. It maintains messages in 
queues for transmission to applications and term1- 
nals, requiring somewhat less buffering at either 
end of the connection. TCAM also handles non- 
SNA communications more directly. With TCAM 
and ACF/TCAM, the access method itself provides 
the translations for start/stop terminals to partici- 
pate in an SNA network. 

With VTAM and ACF/VTAM, users must 
install the Network Terminal Option (NTO) to 
handle asynchronous devices. NTO is essentially 
an enhancement to IBM front-end system software 
and supports protocol conversion. ACF/TCAM 
allows the use of BSC terminals through the emula- 
tion program or partitioned emulation program- 
ming in the 37X5 communication controller. 

In November 1983, IBM announced the SNA 
Network Interconnection (SNI) feature for ACF/ 
VTAM, but not for ACF/TCAM, further encourag- 
ing ACF/TCAM users to follow the upgrade path 
provided by IBM through ACF/TCAM 2.4. The 
latest version of ACF/VTAM supports the full 
functions of ACF/NCP/VS and of the network logi- 
cal data manager, the Net View software, and the 
latest SNA capabilities. Table 1 summarizes SNA 
access methods, the special features introduced 
with each version, and the operating systems com- 
patible with each. 

ACF/VTAM Version 3 Release 3 offers con- 
nectivity enhancements for type 4 and 5 and type 
2.1 nodes. This version also provides enhance- 
ments to Logical Unit 6.2 and VM SNA console 
support. VTAM Version 3 Release 4 offers type 2.1 
node multitail connectivity, dynamic I/O, ongoing 
LU-LU sessions, and LU6.2 selective data encryp- 
tion. | 


Host Subsystems 


A number of host subsystems support SNA appli- 
cations under ACF/VTAM; a dwindling number 


JUNE 1991 


IBM Datapro Reports on 
Systems Network PC & LAN Communications 
Architecture (SNA) 


also support ACF/TCAM. In SNA, a host sub- 
system handles part of the interface between the 
access method and certain kinds of communicating 
applications. For example, JES/2 or JES/3 for large 
mainframes, and POWER/VSE for smaller DOS/ 
VSE systems, support the reception and spooling of 
batch tasks; likewise, TSO supports interactive 
timesharing. 

SNA also permits sessions between applica- 
tions subsystems in different domains. CICS-to- 
CICS and LU6.2-to-LU6.2 applications are 
supported by the Intersystem Connection feature 
(ISC), IMS-to-IMS sessions are supported by the 
multiple systems coupling feature (MSC), and JES- 
to-JES sessions are supported by the Network Job 
Entry (NJE) enhancement. 

The most important host subsystem is the 
Customer Information Control System (CICS/VS), 
a general interface between IBM’s database han- 
dler, DL/1, and data communications through 
ACF/VTAM. CICS handles interactive transaction 
processing; it also handles intersystem communica- 
tions (ISC), SNA LU6, and advanced program-to- 
program communications, SNA LU6.2. 


SNA Network Management Software 

IBM provides a set of host-resident programs for 
network operation, error detection, error correc- 
tion, and management. IBM’s philosophy of net- 
work management requires centrally controlled 
configuration and error reporting for every aspect 
of the network, both physical (devices) and logical 
(sessions), from the logical unit at one end of a ses- 
sion to the LU at the other end. All SNA devices, 
including IBM modems, contain some facility that 
detects and reports errors. 

The principal software component of IBM’s 
network management system is NetView, intro- 
duced in 1986 to replace the Network Communica- 
tions Control Facility (NCCF). With Net View, 
IBM combined all the functions of NCCF, NPDA, 
and NLDM into a single product. NetView also 
provides some functions of the VTAM Node Con- 
trol Application (VNCA) and the Network Man- 
agement Productivity Facility (NMPF). These 
products were combined under Net View to offer 
users a Simpler, yet more complete method of net- 
work management. IBM has also introduced 
NetView/PC, a multitasking personal computer 
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subsystem of Net View that serves as a gateway be- 
tween NetView and other vendors’ network man- 
agement products. 

NPDA runs as an application under NCCF. It 
records failures and degrading conditions on the 
physical SNA network and can initiate trace pro- 
grams to find the sources of network hardware 
problems. NPDA operates through SSCP-PU ses- 
sions between the host access method and the net- 
work’s physical units. 

NLDM also runs as an application under 
NCCF. It records failures and degrading condi- 
tions on the logical SNA network. NLDM records 
certain relevant data on every session: the logical 
units participating, the session type, and the class 
of service. When it detects problems, or on com- 
mand from the operator, NLDM records all header 
and trailer information from a specified session’s 
message units. NLDM is most useful in tracking 
the causes of lost data and in resolving protocol 
incompatibilities between communicating LUs. 

Running under NCCF, the Network Manage- 
ment Productivity Facility (NMPF) is a set of job 
streams, programs, and data sets that can aid net- 
work staff. NMPF helps personnel install, learn, 
and efficiently use many network software pack- 
ages. 

Two additional NCCF applications reduce 
the number of on-site personnel and are the first 
steps toward “‘operatorless’”>» MVS/SP and DOS/ 
VSE computer rooms. The first of these, the Opera- 
tor Communications Control Facility (OCCF), 
implements mainframe control from a remote lo- 
cation via a duplicate console facility. All sites 
must have ACF/VTAM, ACF/VTAME, or ACF/ 
TCAM and 37X5 ACF/NCP. NCCF is, of course, a 
prerequisite, along with MVS/SP plus JES/2 or 
JES/3, or DOS/VSE. 

Since ACF/SNA networks can become quite 
complex, they must be carefully monitored to 
achieve optimum performance. To facilitate this 
monitoring, IBM introduced another subsystem, 
the Network Performance Monitor (NPM). Like 
NCCF, it runs as an ACF/VTAM application. 
NPM provides realtime monitor graphics and his- 
torical analyses of session data and operates as an 
online, interactive monitor and display facility. 
Another monitor system, the SNA Application 
Monitor (SAMON), provides MVS installations 
with the status of various ACF/VTAM applications 
in the network. It can provide the end user with 
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information menus about the network’s ACF/ 
VTAM applications, including a broadcast facility 
to all SAMON terminals. 

NetView Version 2 includes an LU6.2 trans- 
port capability, which enhances system manage- 
ment by providing central site access to non-SNA 
devices within an SNA network. Net View Version 
2 Release 1 offers the Net View Graphic Monitor 
Facility, providing graphic capabilities to monitor 
SNA resources. NetView Version 2 Release 2 in- 
cludes LU6.2 transport that allows IBM- and user- 
written applications on NetView to communicate 
with other applications. 

A communications processor in Emulation 
mode performs a protocol conversion that makes 
the BSC terminals appear as SNA devices to the 
host. In IBM communication controllers running 
ACF/NCP/VS, users can run the EP in a separate 
memory partition from NCP in the mode called 
Partitioned Emulation Program (PEP). In PEP 
configurations, the portion of the network con- 
trolled by EP is functionally and logically separate 
from the SNA network. 

Announced in March 1991, NetView Distribu- 
tion Manager Release 3 (NetView DM Release 3) 
for MVS centrally manages a large SNA network. 
From a mainframe, it can send and install software 
or files on workstations or distributed systems any- 
where 1n a network. 

Another March 1991 announcement, 
NetView Distribution Manager/2, activates auto- 
mated distribution and change management func- 
tions to host-connected OS/2 workstations, and to 
OS/2 or DOS workstations in host-connected or 
standalone LANs. The product implements a wide 
range of functions for SNA/DS, SNA/FS, and 
SNA/MS-CM. 


IBM Information Network 


IBM has taken the global approach to networking, 
and SNA is playing a vital part to accomplish this 
goal. The IBM Information Network provides mar- 
keting, service, and support in the United States 
and in 20 countries. Users can connect their SNA 
networks to IBM’s international network to reach 
leased-line and dial cities in the U.S., Canada, Eu- 
rope, and Japan. Countries with SNA connection 
capabilities include Austria, Belgium, Canada, 
Denmark, Finland, France, Germany, Hong Kong, 
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Ireland, Italy, Japan, Luxembourg, the Nether- 
lands, Norway, Spain, Sweden, Switzerland, 
United Kingdom, and United States. 

In March 1991, IBM announced that the 
APPN features for OS/2 and the 3174 would be 
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used by the IBM Information Network in the net- 
working services it offers customers, such as elec- 
tronic mail, electronic data interchange (EDI), and 
access to a variety of business databases. ll 
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